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DISTRIBUTION OF MULTICAST DATA TO USERS 
FIELD OF THE INVENTION 

The present invention relates generally to communication networks and particularly to 
methods of multicast transmission. 
5 BACKGROUND OF THE INVENTION 

Data transmission networks are used to provide different types of data. Some data, such 
as real time telephony, must be provided quickly, and it is acceptable if a small portion of the 
data is lost. For other types of data, such as executable programs and other files, an entire data 
file must be received without any loss. In the IP protocol suite, the UDP protocol is used for 
10 data requiring fast delivery, while TCP is used for data requiring reliable delivery (i.e., without 
any loss). In the TCP protocol, the receiver continuously transmits acknowledgements on the 
data it receives, and retransmissions are performed when data was not acknowledged. 

When it is desired to provide the same data to many users, multicasting may be used, in 
order to reduce the bandwidth consumption. In multicasting, a single transmission is listened 
15 to by a plurality of receivers. It is generally not practical for each receiver to provide 
continuous acknowledgements of the multicast data directly to the transmitter. Various 
methods, such as described in U.S. Patent 5,541,927 by Kristol, Paul and Sabnani and in U.S. 
patent 6,269,080 to Kumar, the disclosures of which are incorporated herein by reference, were 
suggested to reduce the number of acknowledgements transmitted to the transmitter, by 
20 designating one or more representative acknowledgement providers. In addition, it has been 
suggested, for example in U.S. patent 5,727,002, the disclosure of which is incorporated herein 
by reference, to use a NAK acknowledgement method, in which receivers send 
acknowledgements only for data they did not receive. 

Generally, when a packet was not received by one or more of the receivers, the sender 
25 re-multicasts the packet to all the receivers. In some cases, however, when only a single 
receiver needs to receive a retransmission, the packet is transmitted to that receiver on a point- 
to-point connection, if such a connection is available. 

Cellular phones can be used for receiving video clips and other data, in addition to their 
use for point to point telephone communication. Multicasting the data to the cellular phones or 
30 to other mobile stations allows efficient use of the available bandwidth, such that large 
amounts of data can be provided to the cellular phones without requiring prohibitive amounts 
of bandwidth. In some cases, users are required to subscribe to a multicast service if they 
desire to receive the data. Upon subscribing, the users receive a decoding key which they use 
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in decoding the multicast data. The key may be changed periodically in order to prevent users 
terminating their subscription from being able to decode data transmitted after the end of their 
subscription period. 

A user does not always want to subscribe for a service for a long duration. For 
5 example, in some cases it may be desired to allow users to pay for each piece of data they 
receive, separately. In order to provide a reliable service, it is important to bill clients only if 
they actually received the multicast data. In addition, in order to maximize revenues it is 
desired to maximize the number of users receiving the multicast data. 

In some networks, most users are generally continuously listening to the multicast 
10 channel, such that a multicast message may be transmitted to the users, if desired, without 
previous notice. In other networks, however, the receivers are not continuously tuned onto the 
multicast channel and the receivers must be notified about the transmission in order to tune 
onto the channel at the designated time. Mobile stations, for example, are generally assigned a 
wireless channel only when the data is actually transmitted, in order to conserve battery power 
15 and bandwidth. In such networks, the data source generally transmits a notification message to 
the mobile stations, instructing them to tune onto the multicast channel. 

U.S. patent 6,453,438 to Miller et al., the disclosure of which is incorporated herein by 
reference, describes a method for managing multicast of data to receivers on a receiver list. 
The receivers on the list are notified on the upcoming data transmission and are requested to 
20 reply as to whether they will receive the data. Receivers responding that they will not be able 
to receive the transmission are added to a recovery list. At a later time, an attempt is made to 
provide the data to the receivers on the recovery list. 

The transmission of multicast data in a cell of a cellular network generally requires 
higher power transmission levels than unicast data, in order to allow for all the receivers in the 
25 cell to receive the data. Higher transmission power levels consume more system resources, 
especially in noise-budget cellular networks (e.g., CDMA). 

U.S. patent 6,360,076 to Segura et al., the disclosure of which is incorporated herein by 
reference, describes a method of adjusting the transmission power to the locations of the 
receivers in the cell. Thus, the power and/or bandwidth consumption may be reduced when the 
30 receivers are located, for example, close to the transmitter. 

U.S. patent publication 2003/0007499 to Rajahalme, the disclosure of which is 
incorporated herein by reference, suggests determining whether to use multicast, unicast or a 
combination of multicast and unicast (i.e., some users receive the data in a multicast 



279/03432 

transmission, others in a unicast transmission) in providing data to subscribers within a 
specific cell. According to the '499 publication, broadcasting to the whole cell uses a lot of 
power and usually requires a robust channel coding, because there is no feedback possibility 
for the receivers to indicate lost frames. The '499 publication states that the invention is based 
5 on the premise that the membership of the group communication is known when allocating 
radio resources for the group communication delivery. 

The combination of multicast and unicast is suggested for use when it would be 
cheapest to deliver the data by multicast, but some of the group members are not able to 
receive the broadcast for one reason or another. In other words, the multicast group is handled 
10 as subgroups to which the multicast packet is delivered using different methods. 

SUMMARY OF THE INVENTION 
A general aspect of the present invention relates to using less than optimal measures for 
delivering multicast data to receivers and supplementing receivers that did not receive the 
multicast data properly in point to point unicast transmissions. 
15 An aspect of some embodiments of the invention relates to multicasting a data file to a 

list of receivers, in a network in which receivers are not continuously tuned to a multicast 
transmission channel. The method includes transmitting a notification on an upcoming 
multicast session, for example including the channel on which the multicast will be 
transmitted, to the receivers and performing the multicast session thereafter without receiving 
20 acknowledgements for the notification. It is noted that a receiver that did not receive the 
notification will not be able to receive the multicast transmission. Not using any 
acknowledgement measures for the notification may result in a lower percentage of receivers 
that receive the data file during the multicast transmission. In accordance with the present 
invention, the cost of unicasting the file to a larger number of receivers, due to the fact that 
25 they did not receive the file during multicast, is preferred over the cost of receiving 
acknowledgements from each of the receivers, for receiving the notification. 

Optionally, the notification is transmitted several times in order to minimize the 
chances of a receiver not receiving the notification due to sporadic noise or a transient problem 
in the receiver. Alternatively or additionally, the notification is transmitted with a high 
30 protection level (e.g., a strong FEC). When the receivers are cellular units, the receivers that do 
not receive the notification are generally shut off or not located in a serviced cell and in most 
cases would not be able to receive the multicast transmission even if they received the 
notification. 
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In some embodiments of the invention, the file is delivered to each of the receivers on 
the list using at most a single application layer unicast connection for acknowledgement of 
data reception and receiving data portions not received during the multicast transmission. 
Optionally, beyond the single application layer unicast connection, no other transport layer 
(layer 4, e.g., TCP) connections are established for delivering the multicast file. In some 
embodiments of the invention, beyond the single application layer unicast connection, no other 
network layer (layer 3, e.g., IP) transmission is performed in relation to the delivery of the file. 

In some of these embodiments, no acknowledgements (including negative 
acknowledgements) are transmitted during the data delivery. In some embodiments of the 
invention, the receivers cannot transmit acknowledgements unless a unicast connection is 
established between the receiver and a data server. 

In some networks, receivers cannot transmit uplink messages to the transmitter while 
they are tuned onto the multicast channel. The switching between a multicast channel and a 
unicast channel required for uplink transmission is generally resource consuming and therefore 
it is desired to minimize the number of times a receiver switches between unicast and multicast 
channels. In addition, when there are a large number of receivers, it is desired to reduce the 
number of unicast connections established with the transmitter. 

In some embodiments of the invention, the delivered file is encrypted with one or more 
keys. Optionally, the keys are provided to the receiver in a same unicast connection in which 
20 the receiver acknowledges receiving the entire data file and/or receives supplementary portions 
of the data file or the entire data file. Thus, the entire data file is provided to each of the users 
using a single unicast connection in addition to the multicast transmission. 

Alternatively, the key is provided to at least some of the users in a unicast connection 
separate from the unicast connection used for acknowledgement and/or for data supplement. In 
25 accordance with this alternative, each receiver optionally uses at most two unicast connections 
to receive the data file and any data required for decoding the file. Optionally, no more than 
10-20% of the receivers of the file use two unicast connections, while the remaining receivers 
use only a single unicast connection. The two unicast connections performed by some of the 
receivers are optionally performed consecutively without the receiver tuning onto the multicast 
30 channel between the unicast connections. This alternative is optionally used, for example, 
when the user reviews a portion of the received data before determining whether to view the 
rest of the data. 
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Optionally, beyond the two unicast connections, no other transport layer (layer 4, e.g., 
TCP) or even network layer (layer 3, e.g., IP) transmissions are performed in relation to the 
delivery of the file. 

An aspect of some embodiments of the invention relates to multicasting a data file to a 
list of receivers, in which the file is delivered to each of the receivers on the list using at most a 
single application layer unicast connection for acknowledgement of data reception and 
receiving data portions not received during the multicast transmission. 

An aspect of some embodiments of the invention relates to a method of multicast 
delivery of a data file to receivers. The method includes encoding the data file and providing 
one or more keys required for decoding the file only after the data is provided to the receiver. 
Providing the key only after the data is provided allows using the request for the key as an 
acknowledgment of receiving the file. In addition, providing the key only after the data 
transmission reduces the time available for users to illegally disseminate keys. 

In some embodiments of the invention, the data file multicast to users includes a non- 
encrypted preview portion and at least one encrypted portion. The user may view the preview 
portion and accordingly determine whether to request the key for the encrypted portion. In 
some embodiments of the invention, the at least one encrypted portion may include a plurality 
of portions and the user may determine, independently from each other, for which portions to 
request decryption keys. Optionally, the user may request the key for each portion at different 
times. Alternatively or additionally, the user may determine whether to request a key for one of 
the portions based on viewing one or more of the portions for which a key was previously 
received. Providing a plurality of portions together reduces the amount of signaling required 
for the delivery of the plurality of portions to the receivers. 

An aspect of some embodiments of the invention relates to a method of multicast 
delivery of a data file to receivers. The method includes estimating one or more transmission 
parameter values required to provide the multicast data, on the average, to a percentage of 
receivers lower than 100% and using the estimated parameter value for multicast transmission. 
The receivers that statistically do not receive the data during the multicast transmission are 
optionally provided the data in supplementary unicast transmissions. The percentage of 
receivers for which the transmission parameters are adjusted is selected so that the cost of 
providing the supplementary data in unicast is lower than the extra cost required for adjusting 
the transmission parameters at a higher level. Optionally, the estimation is adjusted to a level 
of reception of between about 90-95% of the receivers. 
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The estimation is optionally performed before each transmission, based on the current 
conditions (e.g., number of receivers, locations of receivers, noise level) of the network. 
Alternatively or additionally, the estimation is performed based on predetermined tests and/or 
assumptions for a plurality of transmissions. 
5 The transmission parameters optionally include the transmission power used, the 

amount of redundancy used in the transmission, the transmission rate and/or any other 
parameter that affects the energy per bit of the transmission. 

An aspect of some embodiments of the invention relates to a method of providing 
encrypted data to a receiver. The data is optionally provided by a first mobile network service 

10 provider, while the key for decrypting the data is provided by a second mobile network service 
provider. The first service provider optionally does not allocate the IP address used to receive 
the data. In some embodiments of the invention, the data is provided through a different 
gateway GPRS support node (GGSN) than the GGSN through which the key is provided. 

In some embodiments of the invention, the data is provided in a multicast data delivery. 

15 An aspect of some embodiments of the invention relates to a method of receiving 

multicast data, in which receivers are notified on an upcoming multicast session and then 
determine whether to tune onto the multicast channel on which the data is provided. Allowing 
the receivers to view the notification on a multicast session as a recommendation, rather than 
an instruction, allows the notification to be provided without specifically identifying the exact 

20 group of receivers to which the notification is directed. Thus, for example, when a file is 
transmitted a second time for those receivers that did not receive the file the first time, there is 
no need to identify the receivers that are to receive the second transmission in the notification, 
or to have the other receivers receive the file a second time. 

In addition, the user may be queried whether to receive the data file after the 

25 notification is received, or may otherwise program the receiver on which files to receive, 
without involving the data server in the process. 

In some embodiments of the invention, the receiver manages a table that indicates the 
multicast groups to which the receiver is subscribed. The receiver table is optionally managed 
in addition to a subscriber list managed by a transmission controller that provides the multicast 

30 data. Upon receiving the notification, the receiver determines the group or groups to which the 
data file referred to by the notification belongs and consults the table to determine whether to 
receive the data file. Alternatively, the user is queried. In some embodiments of the invention, 
the table indicates what is to be done if the user does not provide an answer (e.g., the user is 
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not near the receiver, the receiver is powered off). In some embodiments of the invention, the 
rules on whether to receive a file, query the user and/or not receive a file may depend on one or 
more external parameters not related to the transmission (e.g., the time, date, location of the 
mobile) and/or one or more internal parameters related to the transmission (e.g., file size, 
5 planned transmission rate, expected error rate). 

An aspect of some embodiments of the invention relates to a method of transmitting 
multicast data in a cellular network, in which different cells have different bandwidth allocated 
for the multicast transmission. The data is optionally provided to each of the base stations of 
the cells at a substantially same rate, and each base station transmits a portion of the data that it 
10 can transmit using its available bandwidth for the multicast transmission and drops data 
packets which they cannot transmit on their allocated bandwidth. The dropping of the packets 
is performed in a manner which substantially synchronizes the transmission of the non- 
dropped data packets of different base stations, such that the base stations transmit packets 
representing the same data content at substantially the same time. The term substantially 
15 synchronized refers herein to a gap of at most several packets (e.g., 3-5 packets) between the 
packets transmitted by different base stations and/or a time gap of at most a few seconds (e.g., 
5-10 seconds) between the transmission of the same packet by different base stations. 

Synchronizing the data transmission in the different cells, avoids the possibility of a 
mobile station moving from one cell to another during a multicast session, receiving the same 

20 data packets twice. 

In some embodiments of the invention, the data packets are provided in groups and 
when a first packet of a new group is received, the base stations drop all the data they have of 
an old group. Optionally, the data source periodically transmits synchronization messages to 
the base stations, to keep the base stations synchronized. Alternatively or additionally, the base 
25 stations are configured to have small buffers and when the buffers are full, packets are 
dropped. In an exemplary embodiment of the invention, the buffers of the base stations have a 
small size, for example of between two to five packets, such that synchronization is 
maintained. Optionally, the buffers of substantially all the base stations have the same size. 

In some embodiments of the invention, the data packets transmitted to the base stations 
30 are identical. Alternatively, different data packets, representing the same data content, are 
transmitted to different base stations. 

There is therefore provided in accordance with an exemplary embodiment of the 
invention, a method of multicasting a data file, comprising transmitting a notification on an 
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upcoming multicast transmission to a plurality of receivers designated to receive the multicast 
transmission, tuning by at least one of the plurality of receivers to a multicast channel, 
responsive to the notification, transmitting a data file, from a data server, on the multicast 
channel, without the data server receiving acknowledgements from the receivers on whether 
5 they received the notification, determining receivers designated to receive the multicast 
transmission that did not receive at least a portion of the data file and attempting to deliver the 
data file to the determined receivers. 

Optionally, transmitting the notification comprises transmitting on a multicast or 
broadcast channel. Optionally, transmitting the notification comprises transmitting a unicast 
10 notification to each of the receivers on the designated receivers. Optionally, transmitting the 
notification comprises transmitting substantially only to designated receivers. Optionally, 
transmitting the notification comprises transmitting a message open also to non-designated 
receivers. Optionally, the notification indicates the channel on which the multicast 
transmission will be provided. Optionally, tuning to the multicast channel by at least one of the 
15 receivers comprises determining by each receiver that receives the notification whether to tune 
onto the multicast channel. Optionally, determining by each receiver that receives the 
notification whether to tune onto the multicast channel comprises determining, from the 
notification, a group to which the upcoming multicast transmission belongs and determining 
whether to tune to the multicast channel according to the determined group. 
20 Optionally, determining by each receiver that receives the notification whether to tune 

onto the multicast channel comprises determining by consulting a list stored on the receiver. 

Optionally, determining by each receiver that receives the notification whether to tune 
onto the multicast channel comprises determining based on input received from a user 
responsive to the notification. Optionally, the receivers do not transmit acknowledgements of 
25 reception of the notification, at all. Optionally, the receivers cannot transmit uplink messages 
to the data server, without stopping to listen to the multicast channel. Optionally, attempting to 
deliver the data file comprises delivering the data file in a unicast transmission to each of the 
determined receivers. Optionally, attempting to deliver the data file comprises delivering the 
data file in a multicast transmission to a plurality of the determined receivers. 
30 Optionally, attempting to deliver the data file comprises providing a notification 

message inviting the receivers to download the transmission on a unicast connection, to the 
determined receivers. Optionally, at least 80% of the designated receivers establish only a 
single unicast connection related to receiving the data file. Optionally, substantially aU of the 
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designated receivers establish only a single unicast connection related to receiving the data file. 
Optionally, substantially all of the designated receivers establish up to two single unicast 
connections related to receiving the data file. Optionally, at least a portion of the data file is 
encrypted, requiring one or more decryption keys identified in the transmitted data file. 

Optionally, the receivers request the one or more keys after receiving the data file. 
Optionally, the receivers request the one or more keys after determining that they received 
sufficient data to allow reconstruction of the data file. Optionally, the keys are received on a 
single unicast connection along with any supplementary data required, not received during the 
multicast transmission. Optionally, the method includes receiving acknowledgements from 
receivers that received the notification or at least a portion of the data file, after transmitting 
the data file, wherein determining receivers designated that did not receive at least a portion of 
the data file is performed by determining receivers from which acknowledgments were not 
received. 

Optionally, receiving the acknowledgements comprises receiving a request for 
decryption keys. Optionally, receiving the acknowledgements comprises receiving a request 
for supplementary data not received during the multicast transmission. Optionally, receiving 
the acknowledgements comprises receiving over a different network than the network on 
which the data file was multicast. Optionally, the data file includes a non-encrypted preview 
portion. Optionally, the non-encrypted preview portion is transmitted on the multicast channel 
interleaved with the remaining portion of the data file. Optionally, at least one occurrence of 
the non-encrypted preview portion is transmitted on the multicast channel before transmission 
of the remaining portion of the data file. 

Optionally, tuning onto the multicast channel comprises tuning onto a cellular 
multicast channel. Optionally, tuning onto the multicast channel comprises tuning onto a 
digital video broadcast channel. Optionally, attempting to deUver the data file to the 
determined receivers comprises delivering on a different network than the network on which 
the data file was multicast. Optionally, the notification indicates a plurality of categories to 
which the data file relates and the plurality of receivers comprises receivers designated to 
receive data belonging to different ones of the plurality of categories. 

There is further provided in accordance with an exemplary embodiment of the 
invention, a method of receiving a data file provided in a multicast transmission, comprising 
tuning, by a mobile station, onto a multicast channel, receiving at least one encrypted packet 
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which can be used in reconstructing the data file, on the multicast channel and receiving at 
least one key required for decrypting the at least one packet after receiving the packet. 

Optionally, receiving the at least one encrypted packet comprises receiving a plurality 
of encrypted packets. Optionally, the plurality of encrypted packets require at least two 
5 different keys for decryption. Optionally, the at least one key is received after receiving a 
sufficient number of packets for reconstructing the data file. Optionally, the method includes 
requesting the at least one key after receiving a sufficient number of packets for reconstructing 
the data file and wherein receiving the at least one key is performed responsive to the 
requesting. 

10 Optionally, the requesting of the at least one key is performed responsive to a user 

instruction. Optionally, at least a portion of the data file is not encrypted. Optionally, the user 
instruction is received after displaying the non-encrypted portion of the file to the user. 

Optionally, the non-encrypted portion of the file is received before any encrypted 
portion of the data file. Optionally, the user instruction is received before receiving any 

15 encrypted portion of the data file. Optionally, the user instruction is received after receiving at 
least some of the encrypted packets. Optionally, the file includes a plurality of different 
portions requiring different keys for decryption. Optionally, the keys required for at least one 
portion are received after displaying at least one other portion. Optionally, the keys required 
for at least one portion are received after displaying at least one other portion which was 

20 decrypted. 

Optionally, tuning onto the multicast channel is performed responsive to receiving a 
notification on an upcoming multicast transmission and responsive to a determination that the 
upcoming multicast transmission matches a subscription profile of the receiver. Optionally, the 
determination that the upcoming multicast transmission matches a subscription profile of the 

25 receiver comprises consulting a multicast subscription profile stored on the receiver. 
Optionally, the determination that the upcoming multicast transmission matches a subscription 
profile of the receiver comprises consulting a multicast subscription profile stored on the 
receiver which is configured automatically by instructions from a remote unit. Optionally, the 
determination that the upcoming multicast transmission matches a subscription profile of the 

30 receiver comprises consulting a multicast subscription profile stored on the receiver which is 
configured by a user of the receiver. Optionally, the method includes acknowledging receipt of 
the at least one key, in a manner which allows charging for the data file. 
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There is farther provided in accordance with an exemplary embodiment of the 
invention, a method of transmitting multicast data, comprising estimating one or more 
transmission parameter values required to achieve, on the average, a reception rate of the 
multicast data lower than 100%, by the receivers to which the multicast data is directed, 

5 transmitting the multicast data on a multicast channel, using the one or more estimated 
parameter values, and providing at least supplementary portions of the multicast data to 
receivers that did not receive the multicast data in its entirety on the multicast channel. 

Optionally, the one or more transmission parameters comprise a transmission power 
level and/or a FEC redundancy level. Optionally, estimating the one or more transmission 

10 parameter values comprises estimating based on general network data without relation to 
specific conditions of a current transmission. Optionally, estimating the one or more 
transmission parameter values comprises estimating based on specific conditions of a current 
transmission. Optionally, estimating the one or more transmission parameter values comprises 
estimating based on the number of receivers. Optionally, the multicast channel comprises a 

1 5 data channel of a cellular network. 

There is further provided in accordance with an exemplary embodiment of the 
invention, a method of receiving multicast data in a cellular network, comprising establishing, 
by a mobile station, a data channel, through a first network unit of a first mobile network, 
opening, by the mobile station, a port associated with the data channel, and receiving, by the 

20 mobile station, through the port, multicast data from a multicast channel passing through a 
second network element, belonging to a second mobile network different from the first mobile 
network. 

Optionally, establishing the data channel comprises receiving an IP address for the 
mobile station and/or establishing a packet data context. Optionally, the first and second 
25 network elements comprise GGSNs. Optionally, the method includes receiving a key for 
decrypting the multicast data through the first network element. 

There is further provided in accordance with an exemplary embodiment of the 
invention, a method of transmitting multicast data in a cellular network, comprising providing 
data for multicast transmission to a plurality of base stations having different bandwidth 
30 amounts allocated for multicast transmission, at a same rate, dropping data by one or more of 
the base stations, as required, so that the data can be transmitted by each of the base stations on 
its respective allocated bandwidth for multicast transmission and transmitting the non-dropped 
data such that the data is transmitted by all the base stations substantially synchronously. 
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Optionally, the base stations use a small buffer for the provided multicast data. 
There is further provided in accordance with an exemplary embodiment of the 
invention, a method of transmitting multicast data in a cellular network, comprising 
transmitting a notification on an upcoming transmission of a multicast file, stating a plurality 
5 of categories to which the data file relates and tuning on to a multicast channel by a plurality of 
receivers subscribed to different categories, responsive to the notification. 

BRIEF DESCRIPTION OF FIGURES 
Particular non-limiting embodiments of the invention will be described with reference 
to the following description of embodiments in conjunction with the figures. Identical 
10 structures, elements or parts which appear in more than one figure are preferably labeled with a 
same or similar number in all the figures in which they appear, in which: 

Fig, 1 is a schematic illustration of a cellular network, in accordance with an exemplary 
embodiment of the present invention; 

Fig. 2 is a flowchart of acts performed by network elements in multicasting a file to 
15 mobile stations, in accordance with an exemplary embodiment of the invention; 

Fig. 3 is a flowchart of acts performed by a mobile station in receiving a multicast data 
file, in accordance with an exemplary embodiment of the invention; and 

Fig. 4 is a schematic illustration of first and second public land mobile networks 
(PLMNs), useful in explaining cooperation between networks in providing multicast data, in 
20 accordance with an exemplary embodiment of the invention. 

DETAILED DESCRIPTION OF EMBODIMENTS 
Fig. 1 is a schematic illustration of a cellular network 100, in accordance with an 
exemplary embodiment of the present invention. Network 100 includes a plurality of base 
stations (BTS) 50, which transmit signals to mobile stations 20 in a cell in their vicinity. 
25 Generally, as is known in the art, each group of several base stations 50 are controlled by a 
base station controller (BSC) 22. As is known in the art, BSC 22 may be replaced by other 
units, such as by a radio network controller (RNC). Regular unicast data is transmitted to BSC 
22 through a serving GPRS support node (SGSN) 24 and a gateway GPRS support node 
(GGSN) 26 from an IP core network 28, such as the Internet. 
30 In some embodiments of the invention, in transmission of multicast data to mobile 

stations 20, a data source 30 generates files which are to be multicast to subscribing mobile 
stations 20. Optionally, the generated files are provided to a data server 42, which controls the 
provision of the file in a multicast transmission to mobile stations 20. 
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In some embodiments of the invention, data server 42 includes a forward error 
correction (FEC) unit 32, in which a plurality of FEC packets are prepared to represent blocks 
of the file. The FEC packets are generated using substantially any FEC method known in the 
art, including one-dimensional, two-dimensional, systematic and non-systematic methods. In 
an exemplary embodiment of the invention, a FEC method such as described in Israel patent 
application 154,739, filed March 4, 2003 and/or in Israel patent application 157,885, filed 
September 11, 2003, titled "Iterative Forward Error Correction", the disclosures of which are 
incorporated herein by reference, is used. The FEC packets are optionally transferred to an 
encryption unit 34, which encrypts the FEC packets, forming respective encrypted packets. 
The encryption of the data may be performed using any method known in the art, including 
symmetric and non-symmetric (i.e., public key and private key) methods. In an exemplary 
embodiment of the invention, the encryption is performed as described in Israel patent 
application 157,886, filed September 11, 2003, titled "Secure Multicast Transmission", the 
disclosure of which is incorporated herein by reference. Optionally, each packet or group of 
1 5 packets is marked with an identification of the key to be used in decoding the packet. 

The encrypted packets of each base station 50 are transferred to the base station for 
transmission in a respective cell covered by the base station. In some embodiments of the 
invention, for example as shown in Fig. 1, the encrypted packets are provided through a 
respective point to multipoint unit (PTMU) 40 of the base station. Alternatively, the encrypted 
20 packets are provided to the base station along a data channel passing through GGSN 26, 
SGSN 24 and BSC 22. Optionally, in accordance with this alternative, data server 42 serves as 
a broadcast multicast service center (BMSC). 

In some embodiments of the invention, the multicast data is transmitted by the base 
stations using the currently available bandwidth not used for other connections. Accordingly, 
25 different amounts of bandwidth for multicast may be allocated in different cells. Alternatively 
or additionally, some or all of the cells allocate a fixed bandwidth for multicast transmission. 
The fixed bandwidth is optionally determined according to the load in the cell, such that 
different cells allocate different bandwidth for multicast. 

Optionally, the packets are provided to base stations 50 at a same rate in a 
30 synchronized manner, so . that all the base stations receive the same data at the same time. In 
some embodiments of the invention, base stations 50 (or the BSCs 22 and/or PTMUs 40 
servicing the base stations) whose multicast bandwidth allows a transmission rate lower than 
the rate at which the data packets are received from data server 42, are configured to drop 
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some of the packets in a manner which keeps close synchronization of the transmitted data 
between different cells. Thus, a mobile station, roaming between cells will not receive a large 

number of packets twice. 

In some embodiments of the invention, the base stations 50 (or any other unit that 
5 performs the dropping for the cell) have small buffers (e.g., of the size of 2-5 packets) for the 
multicast data, so that the time difference between transmitting the same data between 
different base stations 50 is relatively small. Alternatively or additionally, the data packets are 
divided into blocks and base stations 50 are configured to drop packets of an old block when a 
first packet of a new block is received. Further alternatively or additionally, data server 42 
1 o transmits periodically an instruction to drop all old packets. 

In some embodiments of the invention, identical packets are provided to all the base 
stations. Alternatively, different packets representing the same data, for example encoded 
using different keys and/or including different FEC protection segments, are provided to 
different base stations 50. The transmission of different FEC protection segments in different 
15 base stations 50 may be used, in addition to or instead of synchronous transmission, in 
avoiding reception of duplicate data by a moving mobile station. 

Data server 42 optionally includes a key server 36, which provides decryption keys to 
mobile stations 20. In some embodiments of the invention, mobile stations 20 receiving the 
file, instructed to display the file, contact key server 36 and request the keys they need for the 
20 decryption. In addition, mobile stations 20 that did not receive all the data during the 
multicast, optionally receive missing data portions from key server 36, acting additionally as a 
supplementary data server, as described below. 

Although data source 30, FEC unit 32, encryption unit 34 and key server 36 are shown 
as separate units, in some embodiments of the invention, one or more of these units are 
25 implemented together. For example, encryption unit 34 and key server 36 may be 
implemented on a single processor and/or may use a common key database. Alternatively, 
FEC unit 32, encryption unit 34 and key server 36 may be implemented by a plurality of 
different units at different locations. 

Optionally, key server 36 provides keys for decryption only to mobile stations 20 that 
30 have subscribed to the multicast data. Users optionally subscribe for receiving the multicast 
data with the data content provider. Alternatively or additionally, users register through the 
cellular service provider. In some embodiments of the invention, data server 42 provides 
multicast data of a plurality of different categories, for example relating to different themes 
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(e.g., sports, news, music, financial information). Categories may also be based on other 
attributes, such as profession of the user and/or predefined groups of users. Optionally, key 
server 36 provides keys for decryption only to mobile stations 20 subscribed to the category to 
which the transmitted file belongs. Alternatively, for some or all the categories, any user 
5 requesting decryption keys is provided the keys and there is no need for prior subscription. 

Optionally, some data files may relate to more than one category and are therefore 
provided to subscribers of all the categories to which they relate. In some embodiments of the 
invention, different notifications are transmitted for each category to which the data file 
relates. Alternatively, a single notification stating the categories to which the data file relates is 
10 transmitted. For example, each notification may include a list of the category numbers to 
which it relates. Alternatively, each notification has fields for all the possible categories and a 
bit is set for each category to which the data file of the notification relates. Each user 
registering to receive multicast data optionally states the categories the user is interested in. 

In some embodiments of the invention, special data files (e.g., an extraordinary news 
15 broadcast, a promotion music or video clip) are provided to all subscribers or to all mobile 
stations, optionally even to those that did not subscribe to any category. 

The user is optionally charged a flat price for the subscription to the multicast service 
and/or for each category the user is subscribed to. Alternatively or additionally, the user is 
charged for each data file for which decryption keys were requested. In providing the keys, key 
20 server 36 optionally marks the identity of the mobile stations 20 requesting keys, for billing 
purposes. Optionally, data files not delivered within a predetermined time are not billed for, or 
are provided for a reduced cost. For example, data files provided in a mailbox of the user due 
to unsuccessful transfer during the multicast, as described below, may be provided at a lower 
fee. Further alternatively or additionally, the transmission costs of some data files, such as 
25 promotion files, are charged to the data provider. 

In some embodiments of the invention, data server 42 manages a subscriber list 44 
which lists for each of the multicast categories, which mobile stations 20 are subscribed to the 
data of the group. The subscription information in subscriber list 44 is optionally used in 
determining whether to provide decryption keys as discussed above. Alternatively or 
30 additionally, the information in subscriber list 44 is used in determining that all the subscribed 
mobile stations 20 received the multicast file, as described hereinbelow. Further alternatively 
or additionally, the information in subscriber list 44 is used to update mobile stations 20 on the 
files they should receive, as described hereinbelow. 

15 



279/03432 



Fig. 2 is a flowchart of acts performed by network elements in multicasting a file to 
mobile stations 20, in accordance with an exemplary embodiment of the invention. Data 
server 42 optionally provides (200) each PTMU 40 with a notification message on an 
upcoming multicast transmission. Responsive to the notification message, PTMUs 40 generate 
5 notification packets which they transmit (202) in their cell. The notification packets optionally 
include a timing of the transmission and a channel on which the transmission is provided. 
Alternatively or additionally, the notifications are generated and/or transmitted using any other 
method known in the art. In an exemplary embodiment of the invention, the notifications are 
generated automatically responsive to opening a multicast data channel. 

10 At the designated transmission time, optionally without waiting for application layer 

acknowledgements of the notification messages, the file is transmitted (204) on the multicast 
channel. After the transmission is completed, and optionally during the transmission, data 
server 42 waits (230) for unicast connections from MSs 20 receiving the multicast 
transmission. On the unicast connections, data server 42, for example key server 36 thereof, 

15 provides (206) supplementary data and provides (208) decryption keys, as discussed below 
with reference to Fig. 3. Data server 42 marks (210) mobile stations 20 that requested keys as 
receiving the data file, for example for billing purposes, as the requesting of the keys serves as 
an indication that the data file was properly received. That is, mobile stations 20 optionally do 
not request keys unless they have received sufficient data to reconstruct the file. 

20 After the waiting period, data server 42 optionally determines (232) which mobile 

stations, subscribed to a multicast group to which the file belongs, did not acknowledge 
receipt of the data file. These mobile stations 20 may, for example, have been turned off, 
located in cells not supporting multicast, did not receive the notification message due to data 
loss and/or did not succeed to establish a unicast connection with key server 36. Optionally, 

25 these mobile stations are notified (235) that the data file is waiting for them. The notified 
mobile stations then optionally establish a unicast connection with key server 36 on which the 
data file is delivered (237) to the mobile station. 

Referring in more detail to transmitting (200) the notification on the upcoming 
multicast, in some embodiments of the invention the same notification message is provided to 

30 each of PTMUs 40 and each PTMU generates a separate notification packet for transmission 
in its cell. Optionally, the notification message includes a time of beginning of the multicast 
transmission and/or a duration of the transmission. In an exemplary embodiment of the 
invention, rather than stating a time for the beginning of the multicast transmission, the 
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multicast transmission is carried out a predetermined time after the notification packet is 
transmitted. The notification message optionally further includes a file size, information on the 
type of FEC used and/or the type of encryption used. For each file transmitted, the notification 
message optionally identifies the multicast category (or categories) to which the file belongs. 

The notification packet transmitted by base station 50 is optionally transmitted on a 
ceil broadcast channel. Alternatively or additionally, the notification packet is transmitted as 
an SMS message to the mobile stations. Further alternatively or additionally, the notification 
packet is transmitted to the mobile stations using their IP address, for mobile stations having 
an IP address. In an exemplary embodiment of the invention, in base stations 50 associated 
with a PTMU 40, the notification packet is generated by the PTMU, while in other base 
stations the notification packet is provided through a regular cell broadcast service. 

In some embodiments of the invention, the notification packet is transmitted to all 
mobile stations 20 in the network, regardless of whether they are registered to receive the 
multicast transmission. Optionally, mobile stations 20 not registered to receive the multicast 
transmission discard the notification in the application layer. Alternatively, the notification is 
transmitted with a sub-channel identity of the mobile stations registered to the list, such that 
the mobile stations 20 not on the list discard the notifications in a low communication layer. 

Although in the above description each file that is multicast has a separate notification 
message, in some embodiments of the invention, a single notification message is used for a 
plurality of files that are multicast. Alternatively or additionally, a plurality of notification 
messages are generated for a single file, in order to increase the chances that at least one of the 
notifications will be received. The notification packets optionally have a high FEC protection 
level, so as to minimize the loss of the notification packet due to an interfering noise. 

Referring in more detail to waiting (230) for unicast connections, in some 
embodiments of the invention, data server 42 optionally waits a predetermined time for 
acknowledgements after the multicast session is completed. The amount of wait time is 
optionally selected according to the number of receivers on the list of mobile stations 20 to 
receive the transmission and/or the transmission rates in the network. 

Referring in more detail to notifying (235) the non-acknowledging mobile stations 20 
that the file is waiting for them, in some embodiments of the invention, the notification is 
transmitted on a short message (e.g., SMS). Optionally, the notification is transmitted a 
plurality of times consecutively in order to reduce the chances that the notification is not 



17 



279/03432 

received. Alternatively or additionally, the notification is transmitted on a low loss channel 
and/or with a high forward error protection. 

Optionally, before downloading the file, the mobile station verifies that it did not yet 
receive the file. In some embodiments of the invention, when a relatively large number of 
mobile stations did not receive the file, the short message indicates an interval in which it is 
best to download the file (different intervals being indicated to different mobile stations), so as 
to reduce the load on data server 42. 

In some embodiments of the invention, data files deUvered (237) on a unicast 
connection are provided in a different, more efficient, format than provided on the multicast 
connection (e.g., using less or no FEC protection). Alternatively, for simplicity, the same 
packets are provided on the unicast connection as on the multicast connection. 

In some embodiments of the invention, mobile stations 20 are required to acknowledge 
receipt of the notification, for example by transmitting a return SMS message. Alternatively, 
mobile stations 20 do not acknowledge receipt of the notifications and notifications are 
retransmitted to mobile stations that do not collect the file within a predetermined time. 

For mobile stations from which an acknowledgement was not received, repeated 
attempts are optionally made to provide the notification, until the data is properly delivered. 
Alternatively, or after a predetermined time (e.g., several hours) and/or a predetermined 
number of attempts, the data file is considered old and no more attempts to deliver the file are 
made. Optionally, a message is sent to a mailbox of the mobile station notifying that the old 
file was not delivered. Optionally, the mobile station 20 can then establish a unicast 
connection with the data server at any time to collect the old file, if desired. Alternatively or 
additionally, the old file is placed in a mailbox of the mobile station 20 such that it can be 
collected therefrom by the user. Optionally, a message reporting the placement of the file in 
the mailbox is transmitted to the mobile station. In some embodiments of the invention, the 
reporting message is transmitted only a period of time after the placement in the mailbox, only 
if the receiver did not pick up the file. Thus, the number of messages required is decreased. 

Alternatively to transmitting (235) a notification to the non-acknowledging mobile 
stations 20, the data file is provided to non-acknowledging mobile stations on a unicast data 
connection established by key server 36 or on an MMS transmission, with each of the mobile 
stations. Optionally, in accordance with this alternative, before providing the file on the 
connection, the mobile station is queried as to whether it has already received the file. 
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Further alternatively or additionally, data server 42 does not manage a subscription list 
at all or does not provide the file to mobile stations 20 that do not request the file. 

Fig. 3 is a flowchart of acts performed by a mobile station in receiving a file in a 
multicast transmission, in accordance with an exemplary embodiment of the invention. Upon 
receiving (250) the notification packet, the mobile station determines (252) whether to receive 
the file, for example, by consulting a subscription profile record on the mobile station, by 
determining whether the file was received already and/or by querying the user. If the file is to 
be received, the mobile station tunes (254) onto the multicast channel on which the file is 
provided, optionally as identified in the notification packet. The mobile station then receives 
(256) packets of the file on the multicast channel. During the packet reception, the receiver 
repeatedly checks (258) if a sufficient group of packets for reconstruction, were received. If 
(258) a sufficient group of packets for reconstructing the file are received during the multicast 
session, the mobile station leaves (262) the multicast channel, possibly during the multicast 
session. 

In some embodiments of the invention, the mobile station determines (263) whether to 
request the keys required for decoding the file. If it is determined to request the keys, the 
mobile station establishes (264) a unicast connection with key server 36. On the unicast 
connection, the mobile station 20 requests (266) the keys it requires in order to decode the 
packets it received, and receives (268) the requested keys on the established unicast 
20 connection. The file is then displayed (270) to the user. 

If (258) a sufficient number of packets were not received during the multicast session, 
the mobile station establishes (260) a unicast connection with key server 36 and requests (272) 
supplementary packets. In some embodiments of the invention, if additional multicast sessions 
for the same data file are 'scheduled, the mobile station waits for the additional session and 
25 does not request supplementary data yet. Key server 36 provides the supplementary packets on 
the unicast connection. Thereafter, the mobile station optionally determines (267) whether to 
request the keys required for decoding the file. If it is determined to request the keys, on the 
same connection, key server 36 optionally provides (268) the keys required for decrypting the 
packets. In some embodiments of the invention, mobile station 20 requests the keys after 
30 receiving the supplementary packets. Alternatively, mobile station 20 requests the keys along 
with the request for supplementary packets. 

Alternatively, the keys and supplementary data are provided on separate unicast 
connections. For example, the connections may be established with two separate units, one of 
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which provides the keys and the other provides supplementary data. Alternatively or 
additionally, the receiver may first receive the entire data file and then ask the user whether to 
request the keys. For example, as described below, the user may first view a preview of the 
data before requesting the keys. In some embodiments of the invention, between the two 
unicast connections, the receiver mobile station 20 does not tune onto the multicast channel 
for additional data, as the required data is supplemented on the first unicast connection. 

In some embodiments of the invention, the received data file includes a non-encoded 
portion which is previewed by the user in order to determine whether to request the keys of the 
encoded portion. A data supplementing connection is optionally established, if necessary, 
before the preview is displayed in order to fill in data required for the preview and a key 
requesting connection is optionally established after the preview, if desired. 
Acknowledgement of data receipt may be supplied on either connection. Charging, however, 
is performed only if keys are requested on the second connection. 

In some embodiments of the invention, the data file includes a plurality of portions 
encoded with different keys. Upon receiving the file, the mobile station requests a first set of 
keys for decrypting a first portion of the file. Thereafter, based on viewing the first portion of 
the file, the user instructs mobile station 20 whether to request keys for one or more additional 
portions of the file. Based on viewing the additional portions, the user may determine whether 
to request keys for further portions of the file. Optionally, the order of requesting keys is 
predetermined, such that key server 36 will not provide keys for a second portion if keys for 
the first portion were not requested. Alternatively, the encrypting is performed in a manner 
which allows decryption only according to the allowed order. In some embodiments of the 
invention, according to the allowed decryption order of the portions, each portion is encrypted 
with a function of all the keys of the previous portions in addition to its key. Thus, each 
portion can only be decrypted after receiving all the keys of the previous portions. 
Alternatively, the last portion is encrypted first with its key. Thereafter, the last portion and the 
previous portion is encrypted with the key of the previous portion. This process is optionally 
continued for all the portions, so that to decrypt a portion its keys and the keys of all the 
portions before it are required. 

In some embodiments of the invention, the user is notified when receiving the first 
portion on the structure of the file and the number of portions it has. The user can then request 
the keys for all the portions at once or request one or more keys in a plurality of separate 
requests. Alternatively, the user is not notified as to the structure of the file in advance, and 
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each time the user requests keys, the user is provided with a set of keys of the next portion. 
Further alternatively, the user may determine which of the portions to decode, in substantially 
any order. 

Alternatively to mobile station 20 automatically requesting the keys for the first 

5 portion, the keys are requested only after receiving an instruction from the user, for example 
after viewing a free preview. In some embodiments of the invention, the file includes a, 
plurality of free previews for different encoded portions. 

Alternatively to the preview portions being non-encoded, the preview portions are 
encoded with a special key for previews. The preview key is optionally provided to 

10 subscribing mobile stations upon subscription, before the file is transmitted on the mobile 
channel. Alternatively, the key is requested by the mobile station after the receiving of the data 
and serves as a first indication of the reception of the data. 

Referring in more detail to receiving (250) the notification packet, in some 
embodiments of the invention, the notification packet includes a low level indication (e.g., a 

15 multicast group address) of the mobile stations to which it is directed, and the mobile station 
provides the notification to the application layer only if the notification packet is directed to 
the mobile station (e.g., the low level indication matches the mobile station). 

Referring in more detail to determining (252) whether to receive the file, in some 
embodiments of the invention, each mobile station 20 manages a subscription profile which 

20 lists the categories to which it is subscribed. Upon receiving the notification packet, the 
mobile station 20 optionally consults its subscription profile to determine whether to receive 
the file referred to in the notification packet. Alternatively or additionally, mobile station 20 
displays or sounds a message to the user, asking whether to receive the file. Optionally, in 
accordance with this alternative, mobile station 20 is configured with default decisions on the 

25 acts to be performed when a response is not received from the user. For example, a mobile 
station 20 may be configured to receive all files of a first multicast category, to ask the user 
about files of a second multicast category but to receive the file if no answer is received and to 
ask the user about files of a third multicast category but not to receive the file unless specific 
instructions were received from the user. It is noted that the decision on whether to receive the 

30 data of the file is separate from the decision on whether to decode the file and pay for it. A 
user may decide, for example, to receive any file that has a fair chance to be decoded, in order 
not to lose time until the file is received, although such reception utilizes the battery power of 
the mobile station. 
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In some embodiments of the invention, the rules on whether to receive a file, query the 
user and/or not receive a file may depend on one or more external parameters not related to the 
transmission (e.g., the time, date, location of the mobile) and/or one or more internal 
parameters related to the transmission (e.g., file size, planned transmission rate, expected error 
rate). 

In some embodiments of the invention, the subscription profile in mobile station 20 is 
configured by the user of mobile station 20, through a user interface of the mobile station, 
according to user preferences. Alternatively, the subscription profile is configured by a control 
message transmitted from data server 42 (or from any other remote network unit), according to 
subscription information in subscription list 44. The control messages are optionally 
transmitted to mobile station 20 periodically and/or whenever there is a change in the 

subscription information. 

Alternatively to mobile station 20 keeping track of the categories of files it is to 
receive, the notification packets are transmitted only to mobile stations 20 that are to receive 
the message, for example using directed unicast SMS messages. Alternatively or additionally, 
upon receiving the notification packet, mobile stations 20 that do not know if they are to 

receive the file, query data server 42. 

In some embodiments of the invention, a mobile station 20 that received the 
notification but will not be receiving the file, although being subscribed to receive the file 
according to subscription list 44, notifies data server 42, so that attempts will not be made to 
deliver the packet to the mobile station on a unicast connection. Alternatively, the mobile 
station does not notify data server 42. Optionally, in this alternative, the mobile station ignores 
the message notifying that the file can be retrieved in unicast or notifies the data server that it 
is not receiving the file upon receiving the message. 

In some embodiments of the invention, the same file is transmitted on the multicast 
channel a plurality of times in order to make sure that as many as possible receivers receive 
the file in a multicast transmission. For example, if after a first multicast session of 
transmitting the file, less than a predetermined number (70-80%) of subscribers acknowledge 
receipt, instead of providing the file in unicast to all the other subscribers, the file is 
30 retransmitted in another unicast session. Alternatively or additionally, a second multicast 
session is used without relation to the number of acknowledgments received, to make sure that 
as many as possible receivers use the multicast session to receive the file. The number of 
multicast sessions is optionally adjusted according to the number of subscribed mobile 
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stations that did not acknowledge reception yet. Optionally, repeated multicast sessions are 
conducted until the number of non-acknowledging subscribers is below a predetermined 
percentage. 

The multicast sessions may be conducted substantially immediately one after the other, 
or may be conducted, at different times of the day, e.g., separated by an hour or two. In some 
embodiments of the invention, each multicast session is preceded by a notification to all the 
subscribers or to all subscribers that did not acknowledge receipt of the file. Delivery of the 
file to non-acknowledging mobile stations is optionally performed after all the multicast 
sessions were completed. Optionally, in these embodiments, in determining (252) whether to 
receive the file, mobile station 20 verifies that the file was not yet received. 

Referring in more detail to tuning (254) to the multicast channel, in some 
embodiments of the invention, the tuning (254) to the multicast channel is performed 
passively by mobile station 20, without exchanging link layer packets with the network. 
Alternatively, before tuning onto the channel, mobile station 20 transmits a link layer message 
to PTMU 40, notifying that the mobile station is interested in receiving the multicast file. A 
PTMU 40 that did not receive responses from any mobile stations 20, optionally does not 
transmit the multicast data. Alternatively or additionally, the link layer responses are used by 
PTMU 40 to determine the layout of the mobile stations 20 interested in the multicast file in 
its cell. In some embodiments of the invention, PTMU 40 determines according to the 
received link layer responses, whether to transmit the data in multicast or in unicast or in a 
combination thereof. Optionally, a cost function is calculated for multicast transmission and 
for unicast transmission and the cheaper alternative is used. In some embodiments of the 
invention, the multicast transmission is given an extra preference score for the possibility that 
mobile stations currently in other cells will enter the cell of the PTMU 40 during the multicast 
transmission. 

In some embodiments of the invention, the link layer responses and/or the determined 
mobile station layout of the cell are used in selecting parameters of the transmission, such as 
the power level of the transmission, the frame error protection and/or any other parameter 
affecting the average energy per bit of the transmission. 

The parameters are optionally selected so as to ensure proper reception of the file by a 
percentage of the mobile stations lower than 100%, for example between 90-95%. Generally, 
ensuring proper reception of the file by 100% of mobile stations 20 in the cell requires a 
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relatively large amount of resources, higher than required for achieving reception by 90-95% 
of the mobile stations and supplementing the rest in unicast. 

Alternatively or additionally, one or more transmission parameters are selected by data 
server 42, so as to achieve a desired percentage of successfully receiving mobile stations 20. 
5 Optionally, the transmission parameters are automatically selected according to periodic 
updates on the state of the network, not received responsive to the current transmission. 
Alternatively or additionally, the transmission parameters are configured by a network 
operator according to the general structure of the network and/or . the desired service 
characteristics. The transmission parameters controlled by data server 42 optionally include 
10 the level of redundancy of the FEC, the transmission rate and/or the number of retransmissions 
of the data. The selection of transmission parameters is optionally performed responsive to the 
average number of receivers, the size of the transmitted file and the network loss rate. 

Optionally, before tuning onto the multicast channel, mobile station 20 requests an IP 
address to be used in receiving the data. The same IP address is optionally used for the unicast 
15 connection. 

Alternatively or additionally to determining (267) whether to request the keys required 
for decoding the file after the supplementary data is received, in some embodiments of the 
invention, the determination is performed before requesting (272) the supplementary data or 
before establishing (260) the unicast connection, such that the supplementary data is not 
20 requested unless the keys will be requested. 

Referring in more detail to establishing (260 or 264) the unicast connection, in some 
embodiments of the invention, mobile stations 20 determine when to request the keys at least 
partially randomly, so that the load on key server 36 is distributed over the waiting period. 
Alternatively or additionally, mobile stations 20 receiving all the data during the multicast 
25 session may contact key server 36 immediately, while mobile stations 20 requiring 
supplementary data contact key server 36 at a random interval after the multicast session. 

Alternatively or additionally, different base stations 50 instruct the mobile stations they 
service, for example in the notification packets, on different times at which they are to contact 
key server 36. Alternatively or additionally, a plurality of key servers are provided and the 
30 notification packets instruct the mobile stations 20 as to which key server they are to contact. 

In some embodiments of the invention, the multicast data may be received even by 
mobile stations 20 that do not have an IP address. Optionally, if the mobile station does not 
already have an IP address, establishing the unicast connection includes requesting an IP 
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address from GGSN 26. In some embodiments of the invention, the unicast connection is 
established through a wireless application protocol (WAP) gateway. Optionally, in some of 
these embodiments, the entire provision of the data file, including the requesting of 
supplementary data and decryption keys is performed without the mobile station having an IP 
address. 

Referring in more detail to determining (263 or 267) whether to request the keys, in 
some embodiments of the invention, the user decides whether to request the keys. Optionally, 
the decision is made based on viewing the preview. Alternatively or additionally to the user 
deciding whether to request the keys, the user and/or a system operator may configure the 
mobile station with rules on when to request the keys automatically. The rules on when to 
request the keys automatically may optionally be the same as the rules for receiving the file 
and/or may be different from the rules for receiving the data. Optionally, the preview portion 
of the file includes information which can be used in automatically determining whether to 
request the keys. For example, in providing sport clips, the data may include the teams 
15 involved or the time during the game. A user may configure his/her mobile to automatically 
request keys for games of a certain team and/or occurring at a specific time during the game. 

Referring in more detail to providing supplementary packets in response to requesting 
(272) supplementary data, optionally, the mobile station determines a minimal set of packets 
required in order to allow reconstruction of the data file and requests these specific packets. 
20 Alternatively, the mobile station notifies server 38 which packets it received and the data 
server determines a minimal set of packets to be provided to the mobile station. Further 
alternatively, the supplementary packets include original packets, even if requiring 
transmission of a larger number of packets than optimal. Further alternatively or additionally, 
during the unicast connection mobile station 20 periodically determines whether it has 
25 sufficient packets for reconstruction and accordingly requests more packets. 

The supplementary packets and/or data files provided on unicast connections are 
optionally provided along with the keys required for decoding the data. Alternatively, the 
supplementary packets and/or the data files provided on unicast connections are provided non- 
encoded. Further alternatively, as with multicast data, the mobile station must request the keys 
30 separately, even if on the same connection, as a verification that the data was properly 
received. 

In some embodiments of the invention, users receiving some of the multicast files are 
encouraged to transfer the files to their friends using a unicast transmission service, such as 
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MMS. The cellular service provider receives revenues from such transmission. In addition, 
such transfer could induce users to subscribe. Alternatively or additionally, some multicast 
files are prevented from being distributed to non-subscribers, for example using digital right 
management (DRM) methods to limit distribution. 
5 In some networks, in order for a mobile station 20 to transmit data on an application 

layer uplink, or even a network or transport layer link, the mobile station needs to leave the 
multicast connection and establish a unicast connection. In order to continue receiving the 
multicast data, the mobile station would need to retune onto the multicast channel. The 
changing of channels is generally time consuming and therefore reduces the transmission 

10 quality. In the above described embodiments, each mobile station 20 is required to transmit 
messages to contact data server 42 only a limited number of times, for receiving the multicast 
file, thus simplifying the network operation in providing multicast data. 

In some embodiments of the invention, each mobile station establishes only a single 
application layer unicast connection in order to receive the multicast data, from the receiving 

15 of the notification to the reconstructing of the file. Optionally, beyond the single application 
layer connection, the mobile stations do not establish any transport or network layer 
connections in connection with receiving the data file. Alternatively to receiving the data on 
an application layer connection, the data may be received using a transport layer connection or 
even a network layer connection without using an application layer. 

20 The uplink transmissions are optionally carried out after the multicast transmission, 

such that there is no need to re-tune onto the multicast channel. 

Uplink application layer transmissions, as well as transport and network layer 
transmissions, generally differ from link layer transmissions in that link layer transmissions do 
not require establishing a connection. In addition, the application layer transmissions are 

25 generally directed to units out of the public land mobile network (PLMN) servicing the mobile 
station, while link layer transmissions are directed to elements of the PLMN. The application 
layer transmissions of substantially all the mobile stations are generally handled by a single 
server or by a plurality of synchronized servers. Link layer transmissions, on the other hand, 
are generally handled by respective local network units which are not synchronized regarding 

30 the data exchanged with the mobile stations. 

In the above exemplary embodiment, the application layer uplink transmissions are for 
requesting supplementary data, requesting decoding keys and/or reception acknowledgement. 
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Alternatively to receiving the entire file before previewing and deciding whether to 
receive the file and/or request the decoding keys, in some embodiments of the invention, the 
preview may be viewed before receiving all the data. Optionally, during the multicast 
transmission, the preview can be reconstructed separately from the encoded data, e.g., there 
5 are separate FEC blocks for the preview. When a receiver determines that it has a sufficient 
number of packets for preview, the receiver optionally reconstructs and displays the preview 
immediately. Thus, the user can decide that the file is not desired even before receiving the 
entire file, so that battery power can be conserved. 

Further alternatively or additionally, the notification packet indicates a series of 
10 transmission sessions. In an exemplary embodiment of the invention, the series of 
transmission sessions includes a preview transmission session and a data file transmission 
session. Optionally, the preview session is carried out a few minutes before the data 
transmission, so that the user has sufficient time to decide whether to receive the file before 
the file multicast session begins. Optionally, acknowledgements are transmitted only after the 
15 data transmission sessions. In some embodiments of the invention, users that are sure they 
want to receive the data file can configure their mobile station to forego receiving the preview. 

In some embodiments of the invention, mobile stations 20 that need supplementary 
packets for the preview contact data server 42 and receive the data packets on a unicast 
connection. Alternatively, supplementary packets for the preview are transmitted during the 
20 file multicast session. In this alternative, mobile stations that did not receive a sufficient 
number of packets during the preview session, and therefore could not view the preview, 
begin receiving the file during the file multicast session, in case the user will decide to receive 
the file when the preview is viewed. If the preview is reconstructed during the file multicast 
session and the user decides not to receive the file, the mobile station is instructed to stop 
25 receiving the file. Optionally, the user configures the mobile station as to whether it waits for 
viewing the preview until the file multicast session or requests supplementary preview packets 
on a unicast connection. It is noted that in these embodiments mobile stations that request 
supplementary preview packets and request the keys for the data file will establish two unicast 
connections in receiving the multicast data file. 
30 Fig. 4 is a schematic illustration of first and second public land mobile networks 

(PLMNs), useful in explaining cooperation between networks in providing multicast data, in 
accordance with an exemplary embodiment of the invention. A mobile station 320 registered 
for service by a PLMN A 302 is currently in a district not serviced by PLMN A, but is 
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serviced by PLMN B 304, which has a cooperation agreement with PLMN A. PLMN B 304 
delivers multicast data to subscribing users, for example using methods described above. The 
delivered multicast data is optionally encrypted and users pay for the decryption keys. 

Generally, as is known in the art, when mobile station 320 enters the area covered by 
5 PLMN B 304, the mobile station registers with PLMN B such that it exchanges periodic 
servicing signals with a BSC 310 of PLMN B or with other control units of PLMN B. PLMN 
B notifies PLMN A that mobile station 320 is serviced by PLMN B. Unicast data connections 
initiated by mobile station 320 are generally tunneled to PLMN A 302 which services the data 
connections. Telephone calls directed to mobile station 320 are received by PLMN A which 
10 forwards the calls to PLMN B. Telephone calls generated by mobile station 320 are generally 
directed through PLMN B. 

In some embodiments of the invention, when PLMN B provides a multicast file, 
mobile station 320 receives the notification packet on the upcoming multicast and determines 
whether to receive the multicast file. The decision is optionally performed without 
15 communicating with PLMN B at all or using only link layer communication with PLMN B. If 
mobile station 320 is instructed by the user to receive the file, the mobile station tunes onto 
the multicast channel and receives the packets of the file. The multicast data is provided from 
a data server 344 of PLMN B through BSC 310. Optionally, PLMN B does not know whether 
mobile station 320 received the multicast data and therefore cannot, for example, generate a 
20 charge data record (CDR) for the mobile station 320. 

Thereafter, mobile station 320 contacts a data server 342 of PLMN A to request 
supplementary data, if necessary, and deciphering keys. The contact with data server 342 is 
optionally performed through an SGSN 333 of PLMN B and a GGSN 337 of PLMN A. Data 
server 342 of PLMN A requests the keys and supplementary data from data server 344 of 
25 PLMN B and provides the keys back to mobile station 320. If unicast delivery is required, e.g., 
mobile station 320 is subscribed to receive the file but did not receive the notification, the 
unicast delivery is performed by data server 342 of PLMN A. Optionally, a data server of 
PLMN A authorizes and charges mobile station 320 for the data file. 

Alternatively to providing the multicast data in a different cellular network, the 
30 multicast data may be provided on a totally different type of network, such as on a terrestrial 
network (e.g., a digital video broadcast terrestrial (DVB-T) network), or a satellite broadcast 
channel (e.g., a digital video broadcast satellite (DVB-S) network or any other digital 
broadcast satellite (DBS) network). Further alternatively, the multicast data is provided in a 
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cellular network, while the supplementary data and/or keys are provided in a different type of 
network, for example on a wireless local area network (WLAN). In some embodiments of the 
invention, the acknowledgement, keys and/or supplementary data may be provided on a 
plurality of networks. Optionally, the receiver attempts to respond on the network with the 
5 most local coverage, e.g., a wireless LAN network. If the transmission on the most local 
network is not successful, the receiver attempts to respond on a network with a greater 
coverage, e.g., a cellular network. If the transmission on the cellular network is not successful, 
an attempt to respond is made on a terrestrial or satellite network, for example on a satellite 
uplink ALOHA channel. 

10 In some embodiments of the invention, PLMN A provides the same multicast data at 

substantially the same time as the data is provided by PLMN B. In this embodiment, PLMN A 
does not need to contact PLMN B for supplementary data. PLMN A may, however, need to 
request the encryption keys from PLMN B. Alternatively, PLMN A does not provide the data 
at the same time as PLMN B. Optionally, PLMN B provides supplementary data upon request 

15 from PLMN A. Alternatively, for example when many supplementary data requests are 
expected, PLMN B provides all the data to PLMN A in parallel to transmitting the multicast 
data. In some embodiments of the invention, supplementary data received by PLMN A is 
cached for further use for a predetermined time in which additional requests may be received. 
In some embodiments of the invention, contacting data server 342 of PLMN A by 

20 mobile station 320 includes establishing a data channel. Establishing the data channel 
optionally includes receiving an IP address and/or a packet data context. The packet data 
context optionally includes setting a QoS for the data channel. 

In some embodiments of the invention, each PLMN advertises a unique ID of the 
PLMN in the control signals it transmits. Different PLMNs optionally communicate with each 

25 other through gateways that are used for security. 

It will be appreciated that the above described methods may be varied in many ways, 
including, changing the order of steps, and the exact implementation used. The methods of the 
present invention may be performed in various protocol layers and may be performed for a 
single transmission system in a plurality of communication protocol layers. It should also be 

30 appreciated that the above described methods and apparatus are to be interpreted as including 
apparatus for carrying out the methods and methods of using the apparatus. 

The present invention has been described using non-limiting detailed descriptions of 
embodiments thereof that are provided by way of example and are not intended to limit the 
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scope of the invention. For example, in some embodiments of the invention, mobile stations 
are required to acknowledge the notification packet and unicast notifications are transmitted to 
non-acknowledging mobile stations. 

It should be understood that features and/or steps described with respect to one 
embodiment may be used with other embodiments and that not all embodiments of the 
invention have all of the features and/or steps shown in a particular figure or described with 
respect to one of the embodiments. Variations of embodiments described will occur to persons 
of the art. 

It is noted that some of the above described embodiments may describe the best mode 
contemplated by the inventors and therefore may include structure, acts or details of structures 
and acts that may not be essential to the invention and which are described as examples. 
Structure and acts described herein are replaceable by equivalents which perform the same 
function, even if the structure or acts are different, as known in the art. Therefore, the scope of 
the invention is limited only by the elements and limitations as used in the claims. When used 
in the following claims, the terms "comprise", "include", "have" and their conjugates mean 
"including but not limited to". 
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CLAIMS 

1 . A method of multicasting a data file, comprising: 

transmitting a notification on an upcoming multicast transmission to a plurality of 
5 receivers designated to receive the multicast transmission; 

tuning by at least one of the plurality of receivers to a multicast channel, responsive to 
the notification; 

transmitting a data file, from a data server, on the multicast channel, without the data 
server receiving acknowledgements from the receivers on whether they received the 
10 notification; 

determining receivers designated to receive the multicast transmission that did not 
receive at least a portion of the data file; and 

attempting to deliver the data file to the determined receivers. 

15 2. A method according to claim 1, wherein transmitting the notification" comprises 
transmitting on a multicast or broadcast channel. 

3. A method according to claim 1, wherein transmitting the notification comprises 
transmitting a unicast notification to each of the receivers on the designated receivers. 

20 

4. A method according to any of the preceding claims, wherein transmitting the 
notification comprises transmitting substantially only to designated receivers. 

5. A method according to any of the preceding claims, wherein transmitting the 
25 notification comprises transmitting a message open also to non-designated receivers. 

6. A method according to any of the preceding claims, wherein the notification indicates 
the channel on which the multicast transmission will be provided. 

30 7. A method according to any of the preceding claims, wherein tuning to the multicast 
channel by at least one of the receivers comprises determining by each receiver that receives 
the notification whether to tune onto the multicast channel. 
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8. A method according to claim 7, wherein determining by each receiver that receives the 
notification whether to tune onto the multicast channel comprises determining, from the 
notification, a group to which the upcoming multicast transmission belongs and determining 
whether to tune to the multicast channel according to the determined group. 

9. A method according to claim 7 or claim 8, wherein determining by each receiver that 
receives the notification whether to tune onto the multicast channel comprises determining by 
consulting a list stored on the receiver. 

10. A method according to any of claims 7-9, wherein determining by each receiver that 
receives the notification whether to tune onto the multicast channel comprises determining 
based on input received from a user responsive to the notification. 

11. A method according to any of the preceding claims, wherein the receivers do not 
transmit acknowledgements of reception of the notification, at all. 

12. A method according to any of the preceding claims, wherein the receivers cannot 
transmit uplink messages to the data server, without stopping to listen to the multicast channel. 

13. A method according to any of the preceding claims, wherein attempting to deliver the 
data file comprises delivering the data file in a unicast transmission to each of the determined 
receivers. 

14. A method according to any of claims 1-12, wherein attempting to deliver the data file 
comprises delivering the data file in a multicast transmission to a plurality of the determined 
receivers. 

15. A method according to any of the preceding claims, wherein attempting to deliver the 
data file comprises providing a notification message inviting the receivers to download the 
transmission on a unicast connection, to the determined receivers. 

16. A method according to any of the preceding claims, wherein at least 80% of the 
designated receivers establish only a single unicast connection related to receiving the data file. 
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17. A method according to claim 16, wherein substantially all of the designated receivers 
establish only a single unicast connection related to receiving the data file. 

5 18. A method according to claim 16 or claim 17, wherein substantially all of the designated 
receivers establish up to two single unicast connections related to receiving the data file. 

19. A method according to any of the preceding claims, wherein at least a portion of the 
data file is encrypted, requiring one or more decryption keys identified in the transmitted data 
10 file. 

.20. A method according to claim 19, wherein the receivers request the one or more keys 
after receiving the data file. 

15 21. A method according to claim 19 or claim 20, wherein the receivers request the one or 
more keys after determining that they received sufficient data to allow reconstruction of the 
data file. 

22. A method according to claim 19, wherein the keys are received on a single unicast 
20 connection along with any supplementary data required, not received during the multicast 

transmission. 

23. A method according to any of the preceding claims, comprising receiving 
acknowledgements from receivers that received the notification or at least a portion of the data 

25 file, after transmitting the data file, wherein determining receivers designated that did not 
receive at least a portion of the data file is performed by determining receivers from which 
acknowledgments were not received. 

24. A method according to claim 23, wherein receiving the acknowledgements comprises 
30 receiving a request for decryption keys. 
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25. A method according to claim 23 or claim 24, wherein receiving the acknowledgements 
comprises receiving a request for supplementary data not received during the multicast 
transmission. 

5 26. A method according to any of claims 23-25, wherein receiving the acknowledgements 
comprises receiving over a different network than the network on which the data file was 
multicast. 

27. A method according to any of the preceding claims, wherein the data file includes a 
10 non-encrypted preview portion. 

28. A method according to claim 27, wherein the non-encrypted preview portion is 
transmitted on the multicast channel interleaved with the remaining portion of the data file. 

15 29. A method according to claim 27, wherein at least one occurrence of the non-encrypted 
preview portion is transmitted on the multicast channel before transmission of the remaining 
portion of the data file. 

30. A method according to any of the preceding claims, wherein tuning onto the multicast 
20 channel comprises tuning onto a cellular multicast channel. 

31. A method according to any of the preceding claims, wherein tuning onto the multicast 
channel comprises tuning onto a digital video broadcast channel. 

25 32. A method according to any of the preceding claims, wherein attempting to deliver the 
data file to the determined receivers comprises delivering on a different network than the 
network on which the data file was multicast. 

33. A method according to any of the preceding claims, wherein the notification indicates a 
30 plurality of categories to which the data file relates and the plurality of receivers comprises 
receivers designated to receive data belonging to different ones of the plurality of categories. 
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34. A method of receiving a data file provided in a multicast transmission, comprising: 
tuning, by a mobile station, onto a multicast channel; 

receiving at least one encrypted packet which can be used in reconstructing the data 
file, on the multicast channel; and 
5 receiving at least one key required for decrypting the at least one packet after receiving 

the packet. 

35. A method according to claim 34, wherein receiving the at least one encrypted packet 
comprises receiving a plurality of encrypted packets. 

10 

36. A method according to claim 35, wherein the plurality of encrypted packets require at 
least two different keys for decryption. 

37. A method according to any of claims 34-36, wherein the at least one key is received 
15 after receiving a sufficient number of packets for reconstructing the data file. 

38. A method according to claim 34, comprising requesting the at least one key after 
receiving a sufficient number of packets for reconstructing the data file and wherein receiving 
the at least one key is performed responsive to the requesting. 

20 

39. A method according to claim 34, wherein the requesting of the at least one key is 
performed responsive to a user instruction. 

40. A method according to claim 39, wherein at least a portion of the data file is not 
25 encrypted. 

41. A method according to claim 40, wherein the user instruction is received after 
displaying the non-encrypted portion of the file to the user. 

30 42. A method according to claim 41, wherein the non-encrypted portion of the file is 
received before any encrypted portion of the data file. 
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43. A method according to claim 42, wherein the user instruction is received before 
receiving any encrypted portion of the data file. 

44. A method according to claim 42, wherein the user instruction is received after 
5 receiving at least some of the encrypted packets. 

45. A method according to claim 34, wherein the file includes a plurality of different 
portions requiring different keys for decryption. 

10 46. A method according to claim 45, wherein the keys required for at least one portion are 
received after displaying at least one other portion. 

47. A method according to claim 46, wherein the keys required for at least one portion are 
received after displaying at least one other portion which was decrypted. 

15 

48. A method according to claim 34, wherein tuning onto the multicast channel is 
performed responsive to receiving a notification on an upcoming multicast transmission and 
responsive to a determination that the upcoming multicast transmission matches a subscription 
profile of the receiver. 

20 

49. A method according to claim 48, wherein the determination that the upcoming 
multicast transmission matches a subscription profile of the receiver comprises consulting a 
multicast subscription profile stored on the receiver. 

25 50. A method according to claim 49, wherein the multicast subscription profile stored on 
the receiver is configured automatically by instructions from a remote unit. 

51. A method according to claim 49, wherein the multicast subscription profile stored on 
the receiver is configured by a user of the receiver. 

30 

52. A method according to claim 34, comprising acknowledging receipt of the at least one 
key, in a manner which allows charging for the data file. 
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53 . A method of transmitting multicast data, comprising: 

estimating one or more transmission parameter values required to achieve, on the 
average, a reception rate of the multicast data lower than 100%, by the receivers to which the 
multicast data is directed; 

transmitting the multicast data on a multicast channel, using the one or more estimated 

parameter values; and 

providing at least supplementary portions of the multicast data to receivers that did not 
receive the multicast data in its entirety on the multicast channel. 

54. A method according to claim 53, wherein the one or more transmission parameters 
comprise a transmission power level. 

55. A method according to claim 53 or claim 54, wherein the one or more transmission 
parameters comprise a FEC redundancy level. 

56. A method according to claim 53, wherein estimating the one or more transmission 
parameter values comprises estimating based on general network data without relation to 
specific conditions of a current transmission. 

57. A method according to claim 53, wherein estimating the one or more transmission 
parameter values comprises estimating based on specific conditions of a current transmission. 

58. A method according to claim 57, wherein estimating the one or more transmission 
parameter values comprises estimating based on the number of receivers. 

59. A method according to claim 53, wherein the multicast channel comprises a data 
channel of a cellular network. 

60. A method of receiving multicast data in a cellular network, comprising: 
establishing, by a mobile station, a data channel, through a first network unit of a first 

mobile network; 

opening, by the mobile station, a port associated with the data channel; and 
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receiving, by the mobile station, through the port, multicast data from a multicast 
channel passing through a second network element, belonging to a second mobile network 
different from the first mobile network. 

5 61. A method according to claim 60, wherein establishing the data channel comprises 
receiving an IP address for the mobile station. 

62. A method according to claim 60, wherein establishing the data channel comprises 
establishing a packet data context. 

10 

63. A method according to claim 60, wherein the first and second network elements 
comprise GGSNs. 

64. A method according to claim 60, comprising receiving a key for decrypting the 
1 5 multicast data through the first network element. 

65. A method of transmitting multicast data in a cellular network, comprising: 
providing data for multicast transmission to a plurality of base stations having different 

bandwidth amounts allocated for multicast transmission, at a same rate; 
20 dropping data by one or more of the base stations, as required, so that the data can be 

transmitted by each of the base stations on its respective allocated bandwidth for multicast 
transmission; and 

transmitting the non-dropped data such that the data is transmitted by all the base 
stations substantially synchronously. 

25 

66. A method according to claim 65, wherein the base stations use a small buffer for the 
provided multicast data. 
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67. A method of transmitting multicast data in a cellular network, comprising: 

transmitting a notification on an upcoming transmission of a multicast file, stating a 
plurality of categories to which the data file relates; and 

tuning on to a multicast channel by a plurality of receivers subscribed to different 
5 categories, responsive to the notification. 



For the applicant, 

10 Fenste^^ Property 2002, Ltd. 
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